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Abstract 

An application was developed to allow users to run and view the Numerical Propulsion 
System Simulation (NPSS) engine simulations from web browsers. Simulations were performed 
on multiple INFORMATION POWER GRID (IPG) test beds. The Common Object Request 
Broker Architecture (CORBA) was used for brokering data exchange among machines and 
IPG/Globus for job scheduling and remote process invocation. Web server scripting was 
performed by JavaServer Pages (JSP). This application has proven to be an effective and 
efficient way to couple heterogeneous distributed components. 

Introduction 

The goal of National Airspace System (NAS)'s Aviation Safety Program (AvSP) is to 
“develop and demonstrate technologies that contribute to a reduction in aviation accident and 
fatality rates by a factor of 5 by year 2007 and by a factor of 10 by year 2022 [1]. To achieve 
this, various simulation systems are used to provide risk assessment and performance parameters 
of aircraft arriving at and departing from airports. In particular, NASA Glenn Research Center s 
Numerical Propulsion System Simulation (NPSS) [2-4] will process flight data and provide 
engine parameters. In this process, the engine simulation module has to handle a huge amount of 
flight data and send the simulation results back to the user across geographic boundaries. A 
typical use case may have a user who initiates processing of a particular data set gathered for 
flights at a specific airport, submits data for engine simulation, and gets the results in 
graphical/tabular format. In this case, the flight data, user interface, and simulation module may 
be hosted by different machines and even by different platforms. In order to achieve this 
scenario, one needs to consider a computational architecture that can incorporate a ubiquitous 
user interface, a heterogeneous computing environment and a high performance computing 
power. 

In this work, an n-tier application was developed to address these issues. The user submits 
simulation requests through a web interface. CORB A/Java technologies are used to build 
middle-tier components. In the back-end, NPSS is used to process flight data and provide engine 
parameters. In order to handle the intensive computational load, NASA's IPG [5] test beds and 
Globus [6,7] were used. In all, our application achieves a web-based, multi -platform, high- 
performance computing environment. 

The following sections describe the components of the system in detail, demonstrate the 
simulation process with various screen snapshots and conclude with future work. 
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Architecture 

Fig. 1 shows the overall architecture of engine simulation. It consists of several machines: (1) 
machines with browser; (2) web server machine hosting JSP, database, flat files, a CORBA 
client and a CORBA server; (3) coupling machine hosting a CORBA server and a CORBA 
client; (4) IPG test beds hosting NPSS engine application and a CORBA client. 
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Figure 1 : Engine simulation architecture 

System Elements 

Web browser, web server and server scripting : 

The advantage of developing a web-based application is that a user can access it from 
anywhere. To run our application properly, the browser needs to have applets enabled. 

Tomcat, a subproject of the open-source Jakarta project, was used as JSP/Servlet engine 
server [8], Version 3.2 of Tomcat supports JSP 1.1 and Servlet 1.2 specifications. Because Java 
is the default and only supported scripting language, it offers several advantages such as easy 
programming, easy database access through JDBC, and code portability. 

Tomcat is very easy to maintain. Two shell scripts were provided to start and stop the server. 
There are two main XML files for configurations: server.xml for the whole server and web.xml 
for each application. Besides running standalone, Tomcat can also run as an Apache module. 
When properly configured, Apache delegates .jsp requests to Tomcat for handling. This allows 
many features of Apache to be leveraged, such as SSL. 

We used JSP files to deliver dynamic web content [9], JSP files may be slow in their first use 
but later invocation is much faster. JSP does much of its real work in JavaBean, such as database 
access and data processing. This allows short JSP files and code reusing. 

Database and flat files: 

Cloudscape 3.0, written in pure Java, is a reliable, high performance DBMS [10] and can be 
installed on many platforms. It provides three frameworks: embedded, RmiJdbc and 
Cloudconnector as well as the corresponding JDBC drivers. We used the RmiJdbc framework to 
support multiple connections. 
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To provide better performance, both flight input data and engine simulation results were 
stored in flat files while simulation configuration data were kept in the database. One reason for 
this design is that flight input data and simulation results are seldom used for quety. On the other 
hand, simulation configuration data are frequently used to look up information. Another reason is 
to avoid data loss. The average number of flight input records is approximately 250. There will 
be about 250 0-Dimensional output records and additional 1000 1 -Dimensional records if 
zooming option is selected. This corresponds to 1250 SQL insert statements that must be done in 
one transaction. If a user ran simulations for two or more flights in a very close time period, data 
loss for one or more flights was sometimes observed. 

A unique job id is assigned to each simulation session that may include one or more flights 
from the same SMA date and one engine model. To easily tell the content of the flat file, the file 
name contains the combination of flight id, flight type (arrival or departure) and SMA date. 

While flight input files are shared, simulation result files are stored under a job id subdirectory 
which allows the same flight input to be used to run multiple simulations with the same or 
different configuration(s). 

CORBA: 

CORBA is the ideal tool to develop distributed applications. All CORBA products support 
HOP protocol. The open source MICO was used as our C++ implementation. MICO works on 
many platforms and supports the CORBA 2.3 specification, especially the Portable Object 
Adaptor (POA) [1 1]. Our MICO applications run on both LINUX and SGI-IRIX (IPG test beds) 
platforms. Firewall configuration is not required. 

Among all the machines used, the coupling machine is the hub. First, the web server 
machine forwards the user's job request through a CORBA client to the CORBA server on the 
coupling machine. The CORBA server then splits the job into sub-jobs, if necessary, by referring 
to the start-up configuration information and using Globus to invoke remote CORBA clients on 
IPG test beds to actually run the sub-jobs. Once the simulation is finished, the results are sent 
back to the CORBA server. The coupling machine stores both flight input and simulation results. 
To make web presentation more efficient, the web server machine has its own local copies of 
both flight input and simulation results. It has a CORBA server running all the time to receive 
simulation results from the coupling machine. The CORBA server on the coupling machine has 
an embedded CORBA client to do this task. 

When the CORBA server on the coupling machine starts up, it runs a start-up script that 
contains the IPG test beds configuration information including grid label, grid DNS name, root 
directory of NPSS application and workload. The information is used to allocate workload and 
locate remote CORBA client. 

Because there may be multiple CORBA clients to request services from the CORBA server 
at the same time, a servant manager of type servant locator was used to provide parallel 
processing. Upon start-up, the server creates 20 inactive objects. At runtime, job id is used as a 
key to use one of the inactive objects. The servant manager then binds the object to a newly 
created servant to serve the request. After serving the request, the servant is deleted and the 
object is inactivated again and reused to serve other requests. 

Globus and IPG test beds: 

The Globus project is developing fundamental technologies needed to build computational 
grids [5-7]. It allows grid users to run jobs on remote grid machines. To achieve this, grid users 
need do three things first: (1) generate a private key and request a Globus certificate; (2) install 
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the private key file and certificate file at home directories on all grids they want to use; (3) have 
their contact string added into Globus mapfiles on all grids they want to use. Globus always uses 
a scheduler such as LSF and PBS to run jobs. In fact, on all grid machines, it is mandatory to use 
a scheduler for long-running jobs. 

Globus allows us to harness the computational power of grid machines. For our application, 
each flight simulation may take 1 -2 minutes. If users want to run 2000 flights (average number 
of flights per day at a large airport), it will take two days to run on a single grid machine. If users 
want to add zooming to their simulation, more time will be needed. By splitting the workload 
onto several grid machines, it is practical to have these simulations done overnight. 

Besides invoking remote CORBA clients. Globus is also used to deliver updated IORs. Each 
time the CORBA server on the coupling machine restarts, CORBA clients need to be aware of 
the newly generated IORs. Globus is used to send these IORS to IPG test beds as well as the web 
browser machine, thus avoiding manual copying of IORs or using a naming service. The 
maintenance of the CORBA server is simply applying for the Globus proxy and starting the 
CORBA server. As mentioned above, there is a CORBA server running on the web server 
machine. When it starts up, it sends its IORs to a web location. The coupling machine is able to 
get the IORs by running a Perl script. 

Engine model: 

NPSS vl .0 was used to run the generic turbofan engine simulation. The model is made of 
elements such as flight conditions, inlet, fan, compressor, burner, turbines, shafts and nozzle. The 
input of the NPSS executable are ground temperature and radar track records (x coordinate, y 
coordinate, range, azimuth, velocity, mach, temperature, timestamp). Radar data is available 
within a fifty- mile radius of the airport. The calculated simulation output parameters include fan 
shaft speed, high speed shaft rpm, compressor inlet & outlet temperatures and pressures, turbine 
inlet & outlet temperatures and pressures, fuel rate, burner efficiency, thrust and CO emission. 

In addition, 1 -Dimensional zooming data including temperature and pressure of both compressor 
and turbine were generated by using a linear algorithm. 

The CORBA clients on the IPG test beds invoke an engine simulation through a shell script 
that sends several parameters including job id and flight id to the NPSS executable. For each 
radar track record, one 0- Dimensional output record is generated. Flights in a job and radar-track 
records of a flight are processed sequentially. Each radar track record is treated independently. 

Demonstration 

A demonstration of the application is available only to users with an assigned user id and a 
valid password. Visitors can click the visitor button to go to a visitor page to view a sample of 
the simulation data including tabular flight input, tabular simulation output, X-Y plots of the 0D 
engine data (applets) and 1 D compressor pressure zooming animation (applet). 

Users who want to run an engine simulation or view history jobs have to login to the system 
through the login page. Passwords are encrypted using a one-way hash function and allowed to 
be changed by the user. After login, the user can either view history jobs or select flights to run 
engine simulation. 
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Figure 2: Job information page. 



Figure 3: Tabular OD engine data. 


If the user knows the job id, this can be entered in a textbox to retrieve the job information 
including user id, run time, SMA date, model id, status and the list of flights in the job. 
Otherwise, a job search can be performed by specifying a query of combination of user id, SMA 
date and run date or simply request showing all jobs. The user selects the job id link to go to the 
job information page (Fig. 2). From the job information page, select the link for the flight to 
navigate to the flight detail page where the tabular input, tabular output (Fig. 3), tabular 
zooming, X-Y plots of OD engine data (applets, Fig. 4, 5), ID temperature and pressure zooming 
animation of both compressor and turbine (applets, Fig. 6), and download input and output data 
can be viewed. 

The user starts the engine simulation by selecting a SMA date (Fig. 7). Then, a list of flights 
with type of either arrival or departure on that date is displayed in a list box (Fig. 8). The user 
can select the flights one by one, or select all arrival flights, or select all departure flights, or 
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Figure 4: Engine parameters available to plot against time step. 



Figure 5: Applet showing X-Y plot of engine parameters. 







select all flights. There are two engine models available for selection: one is a 0-Dimensional 
model without 1 -Dimensional zooming and the other is a O-Dimensional model with 1- 
Dimensional zooming (using a linear algorithm). The selected flights, flight types, model id and 
SMA date specify a job, which is labeled with a unique job id. The Engine simulation of the job 
is triggered by clicking the simulation button. An applet keeps updating to show the progress of 
the job (Fig. 9). From there, the user clicks the job id link to go to the job information page and 
the remaining operations, which were described above. 
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Figure 7: Select SMA date. 




Figure 8: Select flights and engine model. 


Figure 9: Applet showing job status. 
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Future Work 

XML is becoming the de facto standard format for data exchange [13]. Both flight input data 
and engine simulation output will be XML format. Document type definitions (DTD) for the 
format will be defined. Use of XML will facilitate the data flowing in a uniform way but being 
processed in arbitrary ways. 

Another development will be using fast-time data. Instead of storing static input data locally, 
a CORBA server running on a coupling machine will retrieve it from a remote SMA Data Server 
upon request. 
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